An extended bridge is a network topology that is based on the Institute of Electrical and Electronics Engineers (IEEE) 802.1BR standard and comprises two different types of units: a controlling bridge (CB) unit and one or more port extender (PE) units. The CB serves as the controller of the extended bridge and is responsible for performing control plane functions (e.g., Layer 2 switching, Layer 3 routing, etc.) with respect to network traffic that passes through the extended bridge. In contrast the PEs, which connect to the CB and to other network devices/hosts external to the extended bridge, act as non-intelligent devices and thus do not perform any local switching or routing; instead, their primary function is to provide additional data port terminations for the CB. For example, each PE may be a switch/router with X number of physical data ports, which appear as virtual data ports on the CB. Upon receiving a data packet from an external device/host on an ingress data port, the PE forwards the data packet to the CB, which processes the data packet in hardware and/or software to determine an appropriate egress port of the extended bridge through which the packet should be sent out. The CB then forwards the data packet to the PE housing the egress port for transmission through that port towards the next hop destination.
In some cases, an extended bridge may support multiple CBs which connect to each other according to a linear or ring topology. In these cases, one CB may be selected as the “master” CB of the extended bridge and serve as the central point of management for the entire bridge. Other CBs may operate in a “standby” or “member” mode.
The links that interconnect the PEs to each other and to the CB(s) in an extended bridge are known as cascade links. The ports at the endpoints of a cascade link are known as cascade ports. Cascade links are considered internal to the extended bridge since they only carry network traffic that has been tagged with a special ETAG header that is understood by the PEs and CB(s). The ETAG header facilitates the internal routing of traffic from an ingress PE to the CB(s) for processing, as well as from the CB(s) to the egress PE(s) that will forward the traffic out of the extended bridge. For example, in the case of routing a data packet from an ingress PE to a CB, the ETAG header will include an ECID (E-Channel ID) identifying the PE port through which the data packet was received. In the case of routing a data packet from a CB to an egress PE, the ETAG header will include an ECID identifying the PE port through which the data packet should be sent out.
A PE may connect directly to a CB or may connect indirectly to a CB via one or more intermediate (i.e., “transit”) PEs. For example, multiple PEs may form a chain with one end, or both ends, connected to a CB. In the case where both ends of a PE chain are connected to a CB, the PE chain is referred to as a PE ring. Further, each endpoint of a cascade link may be a single physical port or a link aggregation group (LAG) that comprises multiple physical ports but is treated as a single logical port. In this latter case, the cascade link is also referred to as a cascade trunk.
One of the challenges of managing an extended bridge is keeping track of the physical connections between the PEs and CB(s) of the bridge. This can be particularly difficult if some of the PEs/CB(s) are interconnected using cascade trunks, since the CB(s) generally cannot distinguish the individual ports that are part of the cascade LAGs at the endpoints of each trunk (each LAG is identified using a single ECID). One manual approach for determining the port-to-port connections in an extended bridge is for a user to physically trace the cables between the bridge units. However, this manual approach is both time-consuming and error-prone, and thus is not practical in large-scale extended bridge deployments.